home *** CD-ROM | disk | FTP | other *** search
- wt - a 3D game engine
-
- Copyright (C) 1994 by Chris Laurel
-
- Please see the LICENSE file for further details. You may not distribute
- this project without this file (README) and the LICENSE file included.
-
- ---------------------------------------------------------------------------
-
- This is still a preliminary version of my 3D game engine, wt.
-
- * In the proud tradition of cp, mv, rm, as, and cc, now there is 'wt'
- wt (never capitalized) stands for "what's that?"
-
- * This is not by any means a complete game. It is just a demo of my
- graphics engine. I'd never name a game wt.
-
- * wt is portable software. See the section on porting at the end of this
- README for information on what to change in order to port to another
- platform.
-
- * Features:
- * Easy to edit world file. Just haul out your favorite text editor
- and modify 'castle.world' Or create your own .world file from
- scratch. Whee. Just don't get carried away because the world
- file format will be changing before the next release.
- * No BSP trees were killed to make this program. Sorry . . . it's
- late. BSP trees are elegant and fast *if* your environment is
- static. I eventually want walls in wt that move and change shape.
- However, if I can't kill a bug having to do with walls perpendicular
- to the view plane, I may have to resort to a BSP tree for determining
- wall visibility (or if my current algorithm is too slow for worlds
- with a large number of walls.)
- * Variable texture map size. Texture maps for walls can be any
- width you like, but the height must be either 64 or 128. Floor
- textures must be either 64x64 or 128x128. The main reason why
- arbitrary powers of two aren't supported has to do with the fact that
- Intels x86 chips don't have enough registers for my innermost loops.
- * Texture scaling for walls. The walls have an x scale factor and
- a y scale factor. It might be more properly called 'frequency,'
- since the smaller the parameter, the bigger the texture map will
- appear. Supporting the scaling factors requires a couple of extra
- multiplies in the wall drawing function.
-
-
- * Running the demo (this applies to the Linux version only):
-
- * For xwt, just type 'xwt castle.world' The keys are:
- forward - up arrow
- backward - down arrow
- turn left - left arrow
- turn right - right arrow
- strafe - slash
- run - shift
- jump - space
-
- * To run wt, you need to be root (or make it setuid root first.)
- It sucks to have to run a binary you grabbed off the net as
- root, but as far as I know, that's the way it has to be with
- svgalib base programs.
-
- As root, type 'wt castle.world' The keys:
-
- forward - e
- backward - x
- turn left - s
- turn right - d
- strafe left - a
- strafe right - f
- jump - space
-
-
- * Responses
-
- * I received a lot of e-mail from people about the binary-only
- version 0.01 of wt. Thanks for all the interest, and I apologize
- to anyone to whom I did not respond. I've been frying my brain
- on wt.
-
- * While wt does look similar in many respects to DOOM, it is not
- based on any DOOM source code, and I have no connection with Id
- software other than being a customer.
-
- * The most frequently asked question was about the texture file
- format. As you can now tell by looking at texture.[ch], it
- is my own format. There's no reason for this beyond the fact
- that I wanted something for a quick prototyping of the engine,
- and I didn't have any graphic file format specs sitting around.
- I'm open to suggestions about texture file format.
-
- * I will add mouse support for the X11 and svgalib versions. I also
- want to support the Linux keyboard better by setting it to
- RAW mode.
-
- * Your X server needs to support the MIT shared memory extension
- in order for wt to run. Also, it only currently supports an
- 8-bit pseudo color visual. I just haven't had a chance to perfect
- the X code.
-
- * I will eventually design a world editor. It will run under X and
- be based on Tcl/Tk.
-
- * Pitch and roll will not be supported. It's a fundamental constraint
- of the engine design.
-
- * Weird things will happen when you jump above the tops of buildings
- or though the ceiling. You cannot see the tops of buildings--this
- is another design limitation.
-
- * Resizing the view window . . . this does need to be supported. The
- reason why it is not currently supported again has to do with the
- limited register set of the x86 chips. I wanted to keep all my
- variables in registers in the innermost loop, but they would not
- all fit. So, I made the view width an immediate constant . . . if
- I can coax gcc to let me use the ebp register, I'll use that to
- hold the width. Or I could just deal with the (probably minor)
- speed degradation I'd get by reading it from memory.
-
-
- * Room for improvement
-
- * Better texture file format. There's some unnecessary information
- in the texture files now which is left over from a previous 3D
- project.
-
- * Optimizations. There are some obvious ones that I have not gotten
- around to implementing yet. In particular, the multiplies in
- calc_wall_heights can be avoided. I think that the floors code
- can be sped up also. If you know of any improvements to the
- assembly loops in slice.c, *tell me*. I'm not an Intel assembly
- language guru or anything.
-
- * Code cleanup. The core of wt is still in development, so some of
- the code surrounding the renderer is hacky test-the-engine stuff.
- Once wt starts developing into a real game, much of the code
- will be reorganized. wt.c will change completely.
-
-
- * 'Port away!'
-
- * wt now supports both big and little endian machines. The only
- endianness dependent part of the code was in texture.c. If you
- have a big endian machine (pretty much anything but an Intel system)
- you may need to edit the makefile and add -DBIG_ENDIAN to CFLAGS.
- However, my system already has an endian #define, so you may
- not need to do anything.
-
- * There are three types of #define's used to block off non-portable
- sections of the code. ARCH_i86 surrounds the couple assembly
- routines in the wt source. I also surround these with an
- #ifdef __GNUC__ because the inline assembly code syntax in
- gcc is different than for other x86 compilers I've seen. (Anyone
- considering doing an DOS or Windows port take note: the GNU
- assembler uses AT&T syntax, which has the reverse operand order
- of Intel syntax.) Finally, there is a #define to identify
- the graphics system.
-
- * Substitute C routines exist for assembly language functions.
- On a RISC system with a good compiler, I figure you shouldn't need
- to recode them in assembly language. The C functions *should* work.
- I have not tested them in a while, but they were used extensively
- before I rewrote them in assembly.
-
- * Before attempting to compile on a non-UNIX system, #define PROFILE
- to be zero in render.c.
-
- * If you've got a non-Intel system with X11 (or an Intel system
- with X11 which does not have gcc), then you should be able to
- compile wt successfully by just not defining ARCH_i86 in the
- Makefile.
-
- * If you're not running X11, then you'll need to write your own
- graphics and input routines and add a #define for your graphics
- system. Check out linuxvga.c and x11graphics.c for sample
- graphics implementations. All you need is an initialization
- function, a cleanup function, and something to blast a framebuffer
- the screen--memcpy, CopyBits or whatever . . .
-
- * The input system hooks are in input.c. For sample input routines,
- look in linux-console.c and x11input.c. Mac and Windows people:
- x11input.c should give you a good idea about how to tie an
- event handler into wt.
-
- * Send me your ports and I'll include them in the next wt distribution!
- This goes for other improvements to wt, too. Although I love
- hearing ideas, I'm *not* building a game yet. I'm just interested
- in getting the engine working cleanly and quickly on as many
- platforms as possible.
-
- * I'm especially interested in reports about how fast wt will run
- on different platforms (wtStones?) If you do a port, talk to me
- about speed, especially if you have a PowerMac or Alpha system.
- If you port it to a 286, I'm interested but I might laugh.
-
-
- * Future directions:
-
- * I'd like to see wt become a multi-platform client for an
- Internet wide MUD type game. Or a perhaps a net-wide arcade
- game like Xpilot. I've got a lot of other more innovative ideas
- but I'd better get the engine done before I start spouting about
- them.
-
- * CREDITS
-
- Dan Egnor (egnor@ugcs.caltech.edu) - submitted the first set of
- endian fixes.
- Dave Thomas (dave@thomases.demon.co.uk) - wrote up an Imakefile
-
- * Me:
-
- send any comments, ideas, bug reports, etc. to:
-
- Chris Laurel
- home: claurel@mr.net
- work: chrisl@county.lmt.mn.org
- snailmail: 5700 W Lake St, #208
- St. Louis Park, MN 55416
-